1 Logic Programming for Large Scale Applica - tions in

The 1980s saw the rise of one of central projects of AI and Law the representation of law as executable logic programs. [1] describes one of the steps in the development of the project with the representation of a large portion of the United Kingdom’s legislation on “Supplementary Benefit” (SB) as an executable logical model of law in Prolog. It outlines the legislation, the task the representation supports, and problems in creating the representation. One of the earlier, smaller stages in the project were [6], which represented the “British Nationality Act 1981” (BNA) in Prolog. More broadly, it was part of the efforts in other fields to develop expert systems and executable representations of knowledge in general and legal knowledge in particular [7, 5, 3]. The BNA study was a rather constrained, focused, feasibility study of a self-contained article of law that led to a reasonably sized application. There was no method and solutions were ad hoc. The study with SB was intended to see what would happen with a large piece of legislation that had been revised and that interacted with other laws. It was funded by the government of the United Kingdom to create Artificial Intelligence software that supported the application of legislation by government offices, in this case, the Department of Health and Social Services (DHSS), which was a large, complex, organisation tasked with applying social legislation. The SB itself is an extensive piece of legislation (600 pages) including definitions; asides from the legislation, there were auxiliary documents such as a guidance manual. In the end, 90 percent of the legislation was coded over a period of two months, though unsupervised and not evaulated. They distinguish requirements for users of the legislation, e.g. clerks who apply the law need different information, solicitors who advise on how the law is likely to be applied, and individuals or organisations that want to comply with the law. Rather than creating different representations of the same legislation, which would lead not only to redundancy, but possible inconsistency and unclarity, it was proposed to create a logical, executable formalisation of the legislation that could be used as a core across requirements and upon which additional functionalities could be built. For example, it may be useful to provide determinations (from facts to inferences), explanations (from inferences to their proofs), or as compliance monitors (checking that procedures are adhered to). Thus, to maintain a link between the source legislation and the code, the legislation itself is the basis of the translation to logic programming. This was in contrast to [3] that ignored the legislation itself and created an expert system, such as how a clerk might apply the legislation. The approach was to code directly, starting top-down, based on a reading of the legislation, and without a specific methodology or discipline. High-level concepts were defined in terms of lower level concepts, and eventually grounded in facts in a database or supplied by the user. This rule-based approach contrasts with [7], which has a preliminary analysis of legislation in terms of entities